This Background is intended to provide the basic context of this patent application and it is not intended to describe a specific problem to be solved.
New software applications and new versions of existing software applications are continually being developed. Many software applications are designed specifically for the operating system in use at the time the software application is developed. For a variety of reasons, many software applications that are designed for a specific operating system do not work correctly with a new release of the operating system. One reason that an application may not work with a new release of the operating system is that application developers may not always follow the programming specifications provided by operating system developers. For example, operating system specifications typically recommend that application developers use an operating system function to determine the location of a file. However, an application developer may believe that a certain type of file is always stored at a specific location in the computer. Instead of following the operating system specifications and requesting the file location from the operating system, the application developer may specify a certain file location in the application program. This may cause the application to be incompatible with a new release of the operating system that stores the file in a different location than that specified in the applications program.
Even when application developers do follow the procedures recommended by operating system developers, software applications still may not work properly with a new release of an operating system. Often times software developers make assumptions about operating system functions which may not hold true when a new version of the operating system is released. For example, an application developer may assume that a certain function of the existing operating system always returns a certain value if an error occurs within that function. If previous versions of the operating system returned a value of −1 to indicate an error, an application developer may assume that only a −1 value will be returned in the future to indicate the error. A new version of the operating system may, however, modify the function to return other values based on the error, thereby potentially causing the application program to not work correctly in all situations with a new version of the operating system.
In other instances, an application program may seem to operate correctly with one version of an operating system even though the application program contains errors. Applications programs containing errors may operate correctly with operating system that does not detect the errors in the application program. Application programs containing errors may also operate correctly with an older version of the operating system that detects the errors in the application program but does not require that the errors be corrected. A new version of the operating system may check for and require correction of the previously undetected or uncorrected errors thereby causing the application program to be incompatible with the new version of the operating system.
The problems with incompatible applications become more severe as an operating system grows in popularity. When an operating system becomes popular during its release, thousands of applications will be developed specifically for the operating system. The large number of applications, as well as a more diverse group of applications developers, may result in many more applications being incompatible with a new version of the operating system. Users of currently working applications may not want to switch to a newer operating system if their applications will not work correctly with the newer operating system.
There are several approaches that have been used in the past to handle compatibility issues between software applications and operating systems. One approach requires application developers to fix their own applications themselves. One disadvantage of this approach is that not all application developers provide fixes or patches for their applications. Even if application developers do provide a patch for their applications, not all users will obtain and correctly install the patches on their computers. This may result in many applications remaining incompatible with a new release of the operating system.
Another approach to handling incompatible application problems involves operating system developers integrating patches for known problem applications into the new version of the operating system. While the operating system patch approach avoids the problem of relying upon application developers to fix their own applications, the operating system patch approach creates many other problems. First, the patches may add a significant amount of code to the operating system, which may significantly increase the space requirements of the operating system. Second, all applications are required to operate through this additional patch layer even though many applications are compatible with the new operating system and do not need the patches to properly operate. The additional patch layer can cause compatible applications programs to unnecessarily run slower. Third, the operating system programming code may become very cluttered due to the number of application programs that may need to be fixed. The cluttered programming can make it more difficult for the operating system developers to modify and improve the operating system. Finally, it is impossible for an operating system developer to know all of the applications that will not work correctly with a new release of the operating system. Therefore, subsequent patches must be made to the operating system in order to allow these programs to work correctly. This in turn adds another layer to the already complex operating system, which further causes the operating system to operate less efficiently. Therefore, the approach to fixing incompatible applications by providing special code in the operating system can negatively impact other applications as well as the operating system itself.
One approach to solve some of the problems associated with the operating system patch approach described above enables an application to be patched dynamically and reduces the negative effects on other applications and the operating system. This approach may be called a “shimming” approach, where an incompatible application is patched by dynamically inserting a dynamic link library into the incompatible application's address space. The dynamic link library determines the functions in the incompatible application that need to be patched and patches those functions. Calls in the incompatible application are shimmed or redirected to fixes and/or patches in the operating system. A shimming approach, however, does not solve all of the problems of application incompatibility. As described above, operating system developers cannot know all of the applications that will not be compatible with a new release of an operating system. A shimming approach requires each individual incompatible application to be identified and modified in a “post-mortem point-fix” strategy which may result in higher maintenance costs for the software and visible incompatibility issues to the end user.
Another approach to solving incompatibility issues is the use of a virtual machine. A virtual machine is software that creates a virtualized environment between the computer platform and its operating system, so that the end user can operate software (that would be otherwise incompatible with the operating system) on an abstract machine. Compatibility issues are resolved by loading applications onto a virtual machine which contains the environment for which the application was optimized, including the dynamic link library functions of its native operating system version. The virtual instance of the native operating system version appears totally isolated from the actual operating system; the application thinks it is running on its native operating system version and may have less chance of glitches. The virtual machine approach has several disadvantages, though. There is a high performance and memory impact from loading all of the code needed to emulate other operating system versions, especially if more than one virtual machine is needed. Also, applications are totally isolated from the actual operating system, resulting in inconvenience for the end user and inability to utilize components of the actual operating system. For example, if a user created a File A under a virtual machine version A, s/he would need to use the editor and console screen manager of virtual Machine Version A to manipulate File A. The editor and console screen manager of Actual Operating System B would not be able to access File A, nor would the user be able to use New Application B of Actual Operating System B to manipulate File A.
Because of the issues described above, a need exists for an application compatibility approach which minimizes memory and performance issues, minimizes software maintenance costs, is able to address compatibility in a more holistic manner, is more transparent to the end-user and allows the end-user to take advantage of the newer functionality of an operating system.